1. Field of the Invention
The present invention is directed to the field of database management, and, more specifically, to identifying rows which are deleted from and inserted into a base table and storing such changes.
2. Description of the Prior Art
In a database management system (DBMS), a current version of data is generally stored in a “base” table. Each row in the base table may be changed. Such a change may be the deletion, insertion, or modification of a row in the base table. A modification is a deletion of a previous version of a row and an insertion of a current version of a row. When a row is changed, the change may be stored in a set of temporary, memory resident “transition” tables. Such a set of transition tables is generally automatically created and managed by the DBMS. The set of transition tables may include a “delete” table, which stores rows deleted from the base table, and an “insert” table, which stores rows inserted into the base table. If a row is modified, the previous version of the row is stored in the delete table, and the current version of the row is stored in the insert table.
The transition tables enable the DBMS to test the effects of changes and to set conditions for trigger actions. Specifically, transition tables extend referential integrity between tables, change data in a base table underlying a particular view, check for errors and take action based on a detected error, and find the difference between the state of a table before and after a change and take action based on the difference.
In conventional DBMS's, transition tables may be populated by fully copying rows in the base table before such rows are changed. Thus, for example, if a row is deleted, a previous version of the row is copied and the copy is then stored in the delete table. A drawback of copying rows is that such copies are expensive to generate and store, particularly if the copied row includes large fields of binary large object (BLOB) data such as, for example, code or images.
Another method of populating transition tables is to scan a log file. However, a drawback of using such a log scan is that BLOB data is often too complex to implement using the log scan. Furthermore, the log scan requires usage of disk input/output (IO).
Thus, there is a need in the art for systems and methods that efficiently identify and store changes made to a table. It is desired that such systems and methods enable rows including large amounts of BLOB data to be inexpensively identified and stored in an appropriate transition table. It is further desired that such systems and methods operate without inefficient use of disk IO.